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Abstract 

This  paper  presents  adapatations  of  the  Hoare  triple  for  reasoning  about 
concurrent  programs.  The  rules  for  the  Hoare  triple,  familiar  to  program¬ 
mers  from  their  experience  with  sequential  programming,  can  be  applied  to 
develop  proofs  of  concurrent  programs  as  well.  The  basis  for  the  adaptations 
of  the  Hoare  triple  is  temporal  logic. 

1  Introduction 

1.1  Goal 

The  introduction  of  the  Hoare  triple  [4],  more  than  two  decades  ago,  provided 
a  mathematical  foundation  for  reasoning  about  sequential  programs.  Now, 
programmers  are  familiar  with  reasoning  using  the  Hoare  triple  for  sequential 
programs.  This  paper  suggests  that  the  familiar  rules  for  reasoning  with 
Hoare  triples  can  be  applied  to  develop  proofs  of  concurrent  programs. 

This  paper  does  not  propose  a  new  logic  for  concurrent  programs.  The 
foundation  is  provided  by  temporal  logic.  UNITY  [1]  or  TLA  [6]  can  be 
used  to  provide  the  framework  for  the  operators  and  triples  proposed  in 
this  paper.  This  paper  has  the  restricted  goal  of  demonstrating  Hoare-triple 
reasoning  for  concurrent  programs. 

1.2  Triples 

A  relation  F(U,P,V )  where  P  is  a  program,  and  U,  V  are  predicates  on 
states  or  computations,  is  defined  to  be  Hoare-triple-like  if  and  only  if  it 
satisfies  the  following  five  formulae. 

‘Supported  in  Part  by  AFOSR  91-0070. 
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Strengthening  left  side 


(U'  =*  U)  A  F(U,P,V)  =*  F(F',P,F)  (1) 

Weakening  right  side 

F(U,  P,  F)  A  (F  =>  V')  =»  F(t/,  P,  V')  (2) 

Disjunction  of  both  left  and  right  sides 

F(U,  P,  F)  A  F(U',  P,  V')  =*  F(U  V  U',  P,  V  V  F')  (3) 

Conjunction  of  both  left  and  right  sides 

F(U,  P,  V)  A  F(F',  P,  F')  =*  F(F  A  U',  P,  F  A  F')  (4) 


The  Hoare-triple  formula  for  sequential  composition  is  not  included  in  the 
above  set  because  we  shall  propose  Hoare-triple-like  formulae  for  parallel 
composition.  In  place  of  the  formula  for  sequential  composition,  we  use  the 
following  formula: 

Transitivity 

F(U,  P,  F)  A  F(V,  P,  W)  =>  F(U,  P,  W)  (5) 

The  reasoning  about  the  correctness  of  many  concurrent  programs  can  be 
based  on  these  familiar  rules.  Using  a  single  small  set  of  rules  for  reason¬ 
ing  about  sequential  programs,  safety  properties  of  concurrent  programs, 
progress  properties  of  concurrent  programs,  and  parallel  composition,  can 
be  simpler  than  using  many  different  sets  of  rules. 

1.3  Proposal 

In  this  paper,  we  suggest  two  Hoare-triple-like  relations: 

1.  U  t->  F  in  P,  read  “U  to  always  F  in  P”,  to  reason  about  progress 
properties. 

2.  [U]  P  [F],  read  “F  environment  P  F”  to  reason  about  the  parallel 
composition  of  program  P  with  other  programs. 

We  shall  also  use  a  Hoare-triple-like  relation:  U  co  V  in  P,  suggested  by 
Misra  [7],  to  reason  about  safety  properties.  A  goal  of  this  paper  is  to 
suggest  that  these  three  Hoare-triple-like  relations,  and  the  five  rules  (1)  - 
(5)  appear  adequate  for  reasoning  about  many  concurrent  programs. 
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2  Operational  Model 

2.1  Introduction 

The  operational  model  is,  in  essence,  the  operational  model  used  in  UNITY 
[1].  A  program  can  be  thought  of  as  a  fair,  do-od  loop: 

do  g0  -»•  oq[]  •  •  •  []gn  -»  an  od 

where  n  is  finite,  and  for  all  i,  at-  is  a  deterministic  terminating  parallel 
assignment.  The  fairness  requirement  is:  If  holds  at  some  point  in  an 
infinite  computation  then  there  exists  a  later  point  in  the  computation  at 
which  a,-  is  executed  or  gi  does  not  hold.  The  set  of  guarded  commands 
of  the  parallel  composition  of  programs  is  the  union  of  the  sets  of  guarded 
commands  of  the  components.  This  operational  model  is  defined  in  this 
section. 

2.2  Definitions 

Program  A  program  is  a  finite  tuple  of  variables,  and  a  finite  set  of  events. 
The  state  of  a  program  is  given  by  the  tuple  of  values  of  its  variables;  the 
set  of  program  states  is  the  set  of  all  such  tuples.  For  completeness,  we 
define  the  set  of  states  of  a  program  with  an  empty  tuple  of  variables  as  a 
set  consisting  of  a  single  state  Sempty. 

Program  counters  are  treated  as  variables.  Sequential  composition  is 
represented  by  events  that  modify  program  counters  (and  possibly  other 
variables). 

Event  An  event  A  is  a  triple  (W,E,  F): 

1.  Variables  relevant  to  the  event:  W  is  a  nonempty  subset  of  the 
variables  of  the  program. 

2.  Enabledness  of  the  event:  E  is  a  predicate  on  W.  The  event 
(W,  E.  F )  is  defined  to  be  enabled  if  and  only  if  E  holds. 

3.  New  values  of  variables  modified  by  event:  F  is  a  function  that 
maps  from  W  to  W .  If  event  A  is  enabled  in  a  state  S,  and  W  =  Wq 
in  state  S,  then  the  occurrence  of  event  {W,  E,  F )  in  state  S  takes  the 
system  to  a  state  in  which  W  =  F(Wo)  and  the  values  of  all  other 
variables  remain  unchanged. 

In  terms  of  the  fair  do-od  loop,  the  event  (W,  E ,  F)  is  the  guarded  com¬ 
mand: 

E  -  W:=F(W) 
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State  Transitions  Each  state  transition  is  labeled  with  a  single  event. 
There  exists  a  transition  from  a  state  S  to  a  state  S'  labeled  with  event  A 
if  and  only  if  event  A  is  enabled  in  state  S,  and  the  occurence  of  event  A 
in  state  S  takes  the  system  to  state  S'.  Therefore,  there  exists  a  transition 
from  S  to  S'  labeled  with  an  event  A,  where  A  =  (W,E,F),  if  and  only  if 

1.  E  holds  in  state  S,  and 

2.  the  values  of  all  variables  other  than  those  in  W  are  the  same  in  S  and 
S',  and 

3.  if  W  =  Wo  in  state  S,  then  W  =  F(W0 )  in  state  S'. 

Since  F  is  a  function,  for  a  given  state  S  and  a  given  event  A,  there  exists 
at  most  one  transition  from  S  labeled  A. 

If  there  exists  a  transition  from  a  state  5  to  a  state  S'  labeled  A,  then 
we  use  A(S)  to  denote  state  S'.  If  there  exists  no  transition  from  S  labeled 
A  then  A(S)  is  undefined. 

There  can  be  an  arbitrary  number  of  transitions  (each  labeled  with  a 
separate  event)  from  a  state  S  to  a  state  S'. 

Computation  A  computation  is  a  state  So  and  a  sequence  of  events  A{, 
i  >  0,  where  the  i-th  state  Si  reached  in  the  computation  is  defined  recur¬ 
sively  as  follows: 

(Vi :  i  >  0  :  A;  is  enabled  in  Si- 1  A  S{  =  At-(5!_i))  (6) 

and  where  the  sequence  obeys  the  fairness  rule,  given  next. 

Fairness  The  fairness  rule  is  that  in  each  infinite  computation,  if  an  event 
is  enabled  at  some  point  in  the  computation,  then  there  is  a  later  point  in 
the  computation  at  which  the  event  occurs  or  is  disabled. 

For  all  events  B  of  the  program,  and  all  infinite  computations  with  initial 
state  5b,  and  sequence  of  events  A%,  i  >  0,  and  for  all  j: 

(B  is  enabled  in  Sj)  =>  (3k  :  j  <  k  :  (Ak  -  B)  V  ->(B  is  enabled  in  Sk)) 

where  Si,  all  i  are  defined  in  equation  (6). 

Maximal  Computations  A  state  S  is  defined  to  be  a  terminal  state  if 
and  only  if  there  are  no  events  enabled  in  S.  A  maximal  computation  is 
defined  to  be  an  infinite  computation  or  a  computation  ending  in  a  terminal 
state. 
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Programs  and  Concurrent  Composition  The  parallel  composition  of 
programs  P  and  Q  is  a  program  denoted  by  P\\Q.  The  tuple  of  program 
variables  of  P\\Q  is  the  union  of  the  tuples  of  program  variables  of  P  and  Q. 
The  set  of  events  of  P\\Q  is  the  union  of  the  sets  of  events  of  P  and  Q. 

Since  union  is  associative,  commutative  and  idempotent,  it  follows  that 
parallel  composition  is  also  associative,  commutative  and  idempotent. 

The  identity  element  of  parallel  composition  is  a  program  with  an  empty 
tuple  of  variables  and  an  empty  set  of  events. 

3  Program  Properties 

3.1  To  Always 

Let  U  and  V  be  predicates  on  the  states  of  a  program  P.  We  introduce  a 
boolean,  U  ^  V  in  P,  defined  as  follows: 

for  all  maximal  computations  C  of  P:  if  U  holds  at  any  point  i  in  C  then 
there  is  a  point  j  in  C  at  which  V  holds,  and  after  which  V  continues  to 
hold. 

(U^V)mP  = 

(V  maximal  computations  C  of  P  :: 

(3?  :  0  <  i  <  length(C) :  U  holds  in  Si)  =>• 

(3 j  :  0  <  j  <  length(C) :  (yk  :  j  <k  <  length(C) :  V  holds  in  SV))) 

where  Si  is  defined  in  equation  (6),  and  length(C)  is  the  number  of  events 
in  C. 


Theorem  1  The  triple  U  *— ►  in  P  is  Hoare-triple-like. 

Proof:  For  brevity,  we  shall  use  C  for  a  maximal  computation  of  P,  and 
i,  j,  f  for  integers  where  0  <  i,j,j'  <  length(C),  and  k  for  an  integer  where 
j  <  k  <  length(C),  and  k'  for  an  integer  where  /  <  k'  <  length{C). 

Proof  of  strengthening  left  side: 


(fp  =►  U)  A  (U  ^  V  in  P) 

=>  {  (U'  =>  U)  =$■  (Vi  ::  ( U '  holds  in  Si)  =>  ( U  holds  in  St ) )  } 

(VC  ::  (3i  ::  U'  holds  in  Si)  =>  (3i  ::  U  holds  in  Si))  A 
(U  ^  V  in  P) 

=  {  definition  of  } 
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(VC  ::  (3 i  ::  U'  holds  in  Si)  =>  (3 i  ::  U  holds  in  Si))  A 
(VC  ::  (3i  ::  U  holds  in  Si)  =>  (3 \j,\/k  ::  V  holds  in  Sk)) 

=>  {properties  of  V,  and  transitivity  of  =>  } 

(VC  ::  (3i  ::  U'  holds  in  Si)  =>  (3 j,\/k  ::  V  holds  in  Sk)) 

=  {  definition  of  <-*  } 

U’^VinP 

The  proof  of  weakening  the  right  side  is  very  similar,  and  is  left  to  the 
reader. 

Proof  of  conjunction:  Assume  (U  <-+  V  in  P)  A  {U'  <-+  V'  in  P).  The 
proof  is  carried  out  for  any  maximal  computation  C. 

(3* ::  U  A  U'  holds  in  St) 

=>-  {  meaning  of  “holds  in”  } 

(3*  ::  (U  holds  in  Si)  A  (U1  holds  in  Si)) 

=$■  {  property  of  3  } 

(3i  ::  (U  holds  in  Si))  A  (3*  ::  (U1  holds  in  Si)) 

=>  {  (U  ^  V  in  P)  A  (U'  ^  V  in  P)  } 

(3 j,Vk  ::  V  holds  in  Sk)  A  (3 j',Vk' ::  V'  holds  in  Sk< ) 

=  {  for  any  j,  j'  satisfying  this  formula,  set  j  to  max( j,  jr)  } 

(3 j  ■■  (Vk  ::  V  holds  in  Sk)  A  (Vfc  ::  V  holds  in  Sk)) 

=  ,  {predicate  calculus} 

(3j,  VA: ::  (V  holds  in  Sk)  A  {V'  holds  in  Sk)) 

—  {  meaning  of  “holds  in”  } 

(3 j,  Vfc  ::  V  A  V'  holds  in  Sk) 

The  proof  follows. 
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Proof  of  disjunction:  Assume  (U  c->  V  in  P)  A  (U1  <—*  V  in  P).  The 
proof  is  carried  out  for  any  maximal  computation  C. 

(3*  ::  U  V  U'  holds  in  S{) 

=  {  meaning  of  “holds  in”  } 

(3i ::  ( U  holds  in  Si)  V  ( U '  holds  in  Si)) 

=  {  property  of  3  } 

(3* ::  U  holds  in  Si)  V  (3i ::  U'  holds  in  St) 

=>  {  (U  ^  V  in  P)  A  {W  <-+  V  in  P)  } 

(3 j,Vk  ::  V  holds  in  5*)  V  (3 Vfc  ::  V'  holds  in  Sk) 

=  {  property  of  3  } 

(3j  ::  (Vk  ::  V  holds  in  Sk)  V  (V&  ::  V'  holds  in  Sk)) 

=>  {  property  of  V  } 

(3j  ::  (Vfc  ::  (V  holds  in  Sk)  V  (V'  holds  in  Sk))) 

=  {  meaning  of  “holds  in”  } 

(3 j  ::  (Vfc  ::  V  V  V  holds  in  Sk)) 


The  proof  follows. 

The  proof  of  transitivity  is  similar,  and  is  left  to  the  reader. 

3.2  co 

The  definition  of  co,  adapted  from  Misra  [7],  is 
(U  co  V  in  P)  = 

(U  =>  V)  A  (V  events  (W,  E,  F)  of  P  ::  {U  A  E}  W  :=  F(W)  {F}  ) 

Misra  has  shown  from  the  properties  of  Hoare  triples,  and  transitivity  of  =^, 
that  U  co  V  in  P  is  Hoare-triple-like,  and  since  the  set  of  events  of  P\\Q  is 
the  union  of  the  sets  of  events  of  P  and  Q: 

(U  co  V  in  P)  A  (U  co  V  in  Q)  =  (U  co  V  in  P\\Q)  (7) 
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Misra  has  also  shown  that  {U  co  V  in  P)  holds  if  and  only  if  U  =>  V,  and 
for  all  state  transitions  in  P  from  a  state  S  to  a  state  S' ,  if  U  holds  in  state 
S  then  V  holds  in  state  S’. 

3.3  Proving  To-Always  Properties 

We  can  prove  U  <-»•  V  in  P  using  the  UNITY  rule,  see  [1]: 

((U  A  ~>V)  co  ( U  V  V)  in  P)  A  (V  co  V  in  P )  A 
(3  event  (W,E,F)  in  P  ::((U  A -<V)=>  E)  A  {U  A  ->U}  W  :=  F(W)  {F}) 
=>•  U  V  in  P 

The  rule  follows  from: 

1.  (U  A  -iP)  co  ( U  V  V)  in  P  implies  that  if  U  A  ->V  holds  for  a  state  S 
in  a  computation  of  P,  and  S  is  not  a  terminal  state  of  P,  then  in 
the  next  state  either  U  A  ->V  continues  to  hold,  or  V  holds;  therefore 
U  A  -iV  continues  to  hold  forever,  or  eventually  V  holds  [1], 

2.  (3  event  (W,  E,  F)  in  P  ::  ((U A->V)  =>  E)  A  {UA->V}  (W,E,F){V}) 
implies  that  U  A  -W  cannot  continue  to  hold  forever,  because  if  U  A  ->V 
holds  then  the  event  (W,  E,  F )  is  enabled,  and  from  the  fairness  rule, 
eventually  W  :=  F(W)  will  be  executed,  and  that  makes  V  hold. 

3.  V  co  V  in  P  implies  that  if  V  holds  at  any  point  in  a  computation  of 
P  then  it  continues  to  hold  forever  thereafter. 

We  can  also  use  the  five  Hoare-triple  rules  in  proving  U  *— ►  V  in  P.  A 
particularly  valuable  rule  is  weakening  the  right  side.  In  sequential  pro¬ 
gramming,  to  prove  that  a  predicate  X  always  holds,  we  may  have  to  prove 
that  a  stronger  predicate  than  X  is  an  invariant.  Likewise,  to  prove  U  V 
in  P  we  may  have  to  prove  U  t— *■  W  in  P  where  W  is  stronger  than  V. 

Theorem  2 


( U  co  U  in  P)  (U  U  in  P) 

Proof:  Follows  from  the  proof  rule  for  «-»,  substituting  U  for  V. 

4  Compositional  Triples 

Compositional  triples  are  used  in  proving  parallel  composition  of  programs, 
given  the  specifications  (but  not  the  program  texts)  of  the  components. 
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Program  Properties  A  program-property  is  defined  to  be  a  predicate  on 
programs.  We  use  the  abbreviation  “property”  for  program-property  where 
no  ambiguity  results. 

For  a  property  a  and  a  program  P,  we  use  the  notation 

a  in  P 

to  denote  the  boolean:  property  a  holds  for  program  P.  We  define: 

(a  A  fl)  in  P  =  (a  in  P)  A  (/?  in  P)  (8) 

(->a)  in  P  =  -i(a  in  P) 

Hence, 

(a  V  f3)  in  P  =  (a  in  P)  V  (/?  in  P) 

Examples  of  properties  that  we  use  in  reasoning  about  concurrent  programs 
are  U  co  V,  and  U  '-»■  V. 

Let  U  and  V  be  properties,  and  let  P  be  a  program.  A  compositional 
triple  is  a  boolean,  defined  as  follows: 

[U]  P  [V]  =  (V  programs  Q  :  U  in  Q||P  :  V  in  Q\\P) 

The  triple  says  that  if  we  restrict  attention  to  environments  of  P  such  that 
U  is  a  property  of  P  composed  with  its  environment,  then  V  is  a  property 
of  P  composed  with  its  environment. 

Theorem  3  The  relation  [ U ]  P  [F]  is  Hoare-triple-like. 

Proof: 

Proof  of  strengthening  left  side 

(U'^U)A([U]P{V]) 

=T  {(U'^U)  ^  (VQ  :  U'  in  Q\\P  :  U  in  Q\\P)  } 

(VQ  :  W  in  Q\\P:U  in  Q\\P)  A  {[U]P[V]) 

=  {  definition  of  [P]P[F]  } 

(VQ  :  U'  in  Q||P  :  U  in  Q||P)  A  (VQ  :  U  in  Q||P  :  V  in  Q||P) 

=>  {  predicate  calculus  } 

(VQ  :  U'  in  Q[|P  :  V  in  Q||P) 

=  {  definition  of  [Z7,]P[V']  } 

[U']P[V] 
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The  proof  of  weakening  the  right  side  is  similar. 


Proof  of  conjunction 

mnv])A(iu']p{v'}) 

=>  {  definition  of  compositional  triple  } 

(V<2  :  U  in  Q\\P  :  V  in  Q\\P)  A  (V<3  :  U'  in  Q\\P  :  V1  in  Q\\P) 

=  {  predicate  calculus  } 

(V<9  :  (U  in  Q\\P)  A  (P'  in  Q\\P) :  (V  in  Q\\P)  A  {V  in  Q\\P)) 

=  {  equation  (8)  } 

(VQ  :  (U  A  U'  in  <2||P) :  (V  A  V'  in  Q\\P)) 

=  {  definition  of  compositional  triple  } 

[U  A  U']P[V  A  V1] 

Proofs  of  disjunction  and  transitivity  are  similar. 

Proofs  of  Composition  The  following  two  theorems  are  helpful  in  com¬ 
positional  design  of  concurrent  programs. 

Theorem  4  Inheritance:  A  parallel  block  inherits  compositional  triples  of 
its  components. 

mom)  =  w----mQ\mv])  (9) 

Proof: 

w]  q  m 

=  {definition  of  compositional  triple) 

(VP  :  f7  in  Q\\P  :  V  in  <9||P) 

=k  {setting  P  to  Q'\\P'  } 

(VQ;,  P':U  in  Q\\Q'\\P'  :  V  in  Q\\Q'\\P') 

=  {  predicate  calculus  } 
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(VQ'  ::  (VP'  ::  U  in  Q\\Q'\\P'  :  F  in  Q||Q'||P')) 
(definition  of  compositional  triple} 

(VQ'  ::  [U]  Q||Q'  [F]) 


The  proof  that 


(VQ'  ::  ([P]  Q\\Q'[V]))  =>  {{U]Q[V}) 
follows  by  setting  Q'  to  Q,  since  Q||Q  =  Q. 

Corollary  For  any  given  set  of  programs  P0 . . .  Pn: 

(Vi:0<i<n:  [Ut]  P{  [Vt])  =>  (Vi :  0  <  i  <  n  :  [Ui]  P0|| . . .  \\Pn  [V-]) 

Proof:  Follows  from  the  last  theorem,  and  the  associativity  and  commu¬ 
tativity  of  parallel  composition. 

Theorem  5  The  derivation  of  a  compositional  triple  for  a  parallel  compo¬ 
sition  from  the  compositional  triples  of  its  components. 

For  any  given  set  of  programs  P0 .  .  ,Pn: 

(Vi :  0  <  *  <  n  :  [U{]  Pi  [V-])  =» 

[(Vi :  0  <  i  <  n  :  U{)]  P0|| . . .  ||Pn  [(Vi :  0  <  i  <  n  :  V-)] 

Proof:  Follows  from  the  previous  corollary  and  conjunctivity. 

Example  An  example  of  a  compositional  triple  is  given  next. 

Let  U  and  V  be  predicates  on  states  of  programs.  Let  (IT,  E,  F)  be  an 
event  of  a  program  P  such  that 

(([/  A  ->P)  =>  E)  A  {U  A  ->F}  W  :=  F(W)  {F} 

Define  a  program  property  Z  as  follows: 

Z  —  (( U  A  -iF)  co  ( U  V  F))  A  (F  co  V ) 

Then: 

[Z\P[U  ^  V] 

Proof:  For  all  programs  Q: 
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z  in  P\\Q 


=>  {  definition  of  Z,  and  existence  of  event  (W,  E,  F)  in  P  } 

((U  A  -iF)  co  ( U  V  V )  in  P||Q)A  ( V  co  V  in  P||Q)A 

(3  event  (W,  E,  F )  in  P\\Q  ::  (((I  A  ->F)  =>  E)  A  {U  A  ->F}  W  :=  F(W)  {F}) 
{proof  rule  for  ■— ►  } 

17  ^  F  in  P||Q 

5  Example 

5.1  Proof  Restrictions 

In  our  proofs  we  place  two  significant  restrictions  on  ourselves: 

1.  The  only  proof  rules  we  use  are  the  Hoare-triple  rules,  and  the  basic 
rules  for  proving  «— ►  and  co. 

2.  Our  proofs  are  compositional:  the  specification  of  a  composition  of 
programs  is  proved  from  specifications  but  not  the  program  texts  of  the 
components. 

A  potential  concern  is  that  by  restricting  ourselves  in  this  way  we  we  will 
produce  proofs  that  are  much  longer  than  if  we  use  the  full  power  of  temporal 
logic  or  if  we  use  program  texts.  Our  hypothesis  is  that  many  programs 
can  be  designed  so  that  they  can  be  proved  with  the  restrictions,  without 
significantly  increasing  the  length  or  complexity  of  proofs. 

In  the  next  section  we  present  a  simple  example  of  a  concurrent  program 
proof  using  triples. 

5.2  The  Problem 

The  problem  is  a  slightly  more  complex  version  of  the  earliest  meeting  time 
example  in  [1].  A  parallel  composition  of  three  professors,  P,-,  0  <  i  <  3,  and 
a  secretary  Sec ,  computes  the  earliest  time  at  which  all  three  professors  can 
meet.  Time  ranges  over  the  nonnegative  integers. 

Professor  P,  has  input  x  and  output  yt,  all  i.  Associated  with  Pi  is  a 
function  /,,  where  ft(k)  is  the  earliest  time  at  or  after  k  that  Pt-  can  meet. 

If  Vi  <  fi(x)  then  Pi  nondeterministically  selects  some  value  in  the  range 
Hi  ■  ■  ■  fi(x),  and  sets  y,-  to  this  value.  If  yi  remains  less  than  /,( x )  then 
eventually  Pt-  will  increase  yt. 

The  secretary  Sec  has  input  yt,  all  i,  and  output  x.  If  x  <  max,-  yt,  then 
Sec  nondeterministically  selects  some  value  in  the  range  x . .  .max,-  yi,  and 
sets  x  to  this  value.  If  x  remains  less  than  max,-  yt  then,  eventually  Sec  will 
increase  x. 
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Let  e  be  the  earliest  common  meeting  time  of  all  professors: 

e  =  (min  t :  t  >  0  A  t  —  ft(t)  :  t) 

We  are  given  that  e  exists  and  is  finite. 

We  wish  to  prove  that  if  (0  <  x  <  e)  A  (Vi  ::  y%  <  e)  at  any  point  in  a 
computation,  then  eventually  (x  =  e)  A  (Vi  ::  yi  =  e )  in  the  computation. 

A  sequential  program  that  computes  e  is: 

x  0;  while  x  ^  g(x)  do  x  :=  g(x);  {  Assert:  x  =  e  } 

where  g(x)  =  max,-  fi(x).  An  invariant  of  the  loop  is  x  <  e,  since  0  <  e,  and 

x  <  e  =>  g(x)  <  e 

A  variant  function  for  the  loop  is  e  —  x.  At  termination  of  the  program, 
x  =  g(x),  and  the  loop  invariant  holds,  and  hence  x  =  e. 

From  the  program,  it  follows  that  there  exists  a  finite  N  such  that 

<?»  =  c 

where  gk  is  k  successive  applications  of  function  g. 

Next,  we  give  the  formal  specification  of  the  problem. 

5.3  Specification  of  Professors 

1.  Variables  of  P,-  are  x  and  yi. 

2.  Professor  i  does  not  modify  x: 

(x  —  k)  co  {x  -  k )  in  Pi 

3.  Professor  i  does  not  decrease  r/,-: 

nondecreasing(yi )  in  Pi 

where  the  property  nondecreasing(z)  is  defined  as 

nondecreasing(z)  =  (Vfc  ::  (z  >  k )  co  (z  >  k )) 

4.  Professor  i  does  not  set  yi  to  larger  than  the  next  meeting  time  at  or 
after  x. 

(x  <  k)  A  (Vi  <  fi(k))  co  (yi  <  fi(k ))  in  Pi 

5.  If  x  and  t/,  are  nondecreasing  in  any  program  that  has  Pt  as  one  of  its 
components,  then  (x  >  k)  *->■  (yt  >  fl(k))  in  that  program. 

[nondecreasing(x,yi)\  Pt  [(*  >  k)  •—>  (Vi  >  /,-(&))] 

where  the  property  nondecreasing(x ,  ?/,-)  is  defined  as: 

nondecreasing(x,yi)  =  nondecreasing(x)  A  nondecreasing(yi ) 
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5.4  Specification  of  the  Secretary 

1.  Variables  of  Sec  are  x ,  and  t/,-,  i  =  0, 1, 2. 

2.  The  secretary  does  not  modify  all  i. 

(Vi  ::  yi  =  rrii)  co  (Vi ::  t/,-  =  m,-)  in  Sec 


3.  The  secretary  does  not  decrease  x. 

nondecreasing(x )  in  Sec 

4.  The  secretary  does  not  set  x  to  larger  than  the  maximum  of  the  yt  all 
i. 

(Vi ::  yi  <  m,-)  A  (x  <  max,-  ra,-)  co  (x  <  max,-  m,-)  in  Sec 

5.  If  a;  and  t/,-,  all  i,  are  nondecreasing  in  any  program  that  has  Sec  as 
one  of  its  components,  then  (Vi  ::  yi  >  iru )  c—  (x  >  max,-  m,-)  in  that 
program. 

[nondecreasing(x,  y0,  y1,  y2)\  Sec  [(Vi  ::  y{  >  m,-)  ^  (x  >  max,-  m,-)] 

5.5  Stability 

Let: 

W  =  (x  <  e)  A  (Vi  ::  ?/,-  <  e) 

Let  us  prove 

W  co  W  in  Pi 

Proof: 

From  the  specification  of  P,-: 


(x<k)  A  (y{  <  fi(k ))  co  (y,  <  /,-(fc))  in  P,- 

{substituting  e  for  k,  and  using  /,-(e)  =  e} 

(x  <  e)  A  (?/,-  <  e))  co  (?/,-  <  e)  in  P, 

^  {Using  conjunctivity,  and  (^  <  e)  co  (%  <  e)  in  P,-,  for  j  ±  i 
since  yj  is  not  a  variable  of  P,-,  and  (x  <  e)  co  (x  <  e)  in  P, 
since  x  is  not  modified  by  P,-} 

IT  co  IT  in  Pi 

The  proof  of  IT  co  IT  in  Sec  is  very  similar  and  is  not  given  here.  The  proof 
of  IT  co  IT  in  R,  where  R  =  P0||P1||P2||5ec  follows  from  the  composition- 
ality  of  co,  equation  (7). 
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Monotonicity  Next  we  prove: 

(x  >  k )  co  ( x  >  k)  in  P 
Proof:  From  the  specification  of  Sec: 

(x  >  k)  co  ( x  >  k)  in  Sec 
Since  x  is  not  modified  by  Pt,  all  i. 

(x  >  k)  co  ( x  >  k )  in  P, 

From  the  above  two  equations  and  equation  (7) 

( x  >  k )  co  ( x  >  k)  in  P 

The  proof  of  (yt  >  m,-)  co  ( ?/,•  >  m,)  in  P  is  almost  identical. 


5.6  Progress 

Next  we  shall  prove: 

(x  >  0) 

Proof: 

From  the  specification  of  P,-: 


(x  >  e)  in  R 


(  Vi  ::  [nondecreasing(x ,  ?/,)]  Pt-  [x  >  k  ^  Vi>  fi{k )]  ) 

=>  {we  have  proved  nondecreasing(x ,  yi)  all  i  in  R  } 

(Vi  ::  x  >  k  <->  yi  >  fi(k )  in  R) 

=>  {Conjunction} 

(x  >  k)  (Vi  ::  yi  >  fi(k))  in R 

=»  {  We  can  prove  similarly,  using  the  specification  of  Sec 

(Vi  ::  yi  >  fl(k))  ^  (x  >  ma x,-/,-(fc))  in  R 
and  using  transitivity,  and  g(k)  =  ma x,- /,-(&)} 

(x  >  k)  <—>  (x  >  g(k ))  in  P 

=>  {Transitivity} 

(a:  >  fc)  (x  >  gN(k ))  in  P 

=>  {Substitute  0  for  k,  and  use  gN( 0)  =  e} 

(x  >  0)  t-»-  (x  >  e)  in  P 
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5.7  Termination 

Finally  we  prove: 


(0  <  x  <  e)  A  (Vi  ::  yi  <  e)  <->  (x  =  e)  A  (Vi  ::  yi  =  e)  in  R 

Proof: 

We  have  shown: 

(x  >  0) c— >■  (x  >  e)  in  R 

=>  {transitivity,  using  x  >  k  <-*  yi  >  fi(k )  in 

which  we  proved  in  the  last  theorem,  and  substituting  e  for  k,  and 
using  /j(e)  =  e,  and  taking  conjunction  over  all  i  } 

(x  >  0)  (Vi ::  y,-  >  e)  in  R 

=>■  {conjunction  of  the  last  two  and  IF  <-^y  W} 

(0  <  x  <  e)  A  (Vi ::  t/,-  <  e)  <->•  (x  =  e)  A  (Vi ::  y,-  =  e)  in 

6  Evaluation,  Further  Work,  and  Past  Work 

6.1  Monotonicity,  Auxiliary  Variables  and  Progress 

Part  of  the  specification  for  a  mutual-exclusion  program  has  the  form:  If  P 
is  waiting  to  enter  its  critical  section  then  in  a  finite  number  of  steps,  P  will 
be  in  its  critical  section.  The  predicate  in  critical  section  holds  for  only  a 
finite  number  of  steps,  so 

waiting  for  critical  section  <-»•  in  critical  section 

does  not  hold  for  a  mutual-exclusion  program. 

Often,  the  progress  property  for  mutual  exclusion  is  specified  as: 

waiting  for  critical  section  in  critical  section 

where  U  ^  V  is  defined  as:  if  U  holds  at  some  point  in  a  computation  then 
V  holds  at  a  later  point  in  the  computation  [6,  1].  But,  U  V  in  P  is  not 
Hoare-triple-like  because  it  does  not  satisfy  conjunctivity.  A  central  question 
for  the  approach  proposed  in  this  paper  is:  Can  we  specify  and  reason  about 
concurrent  programs  using  only  triples  that  satisfy  the  five  rules:  (1)  -  (5)  ? 
This  issue  is  explored  in  the  next  two  paragraphs. 

Programs  are  designed  with  some  concept  of  “progress”  in  computations 
—  informally  speaking,  more  has  been  accomplished  at  a  later  point  in  a 
computation  than  at  an  earlier  point  in  the  computation.  The  concept  of 
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progress  in  terms  of  “more  being  accomplished”  is  appropriate  even  for  non- 
terminating  programs  such  as  database  systems:  for  instance,  more  transac¬ 
tions  have  been  processed  later  in  the  computation.  The  notion  of  progress 
can  be  captured  by  variables  (  or  auxiliary  variables)  that  are  monotone  non- 
decreasing,  and  where  as  more  gets  accomplished,  the  variable  gets  larger. 
The  value  of  such  a  variable  is  a  measure  (and  there  can  be  many  measures) 
of  progress,  and  so  we  call  such  variables  progress  variables.  In  a  database 
system,  an  example  of  a  progress  variable  is  the  number  of  transactions  that 
have  been  processed. 

In  the  case  of  the  mutual-exclusion  problem,  examples  of  progress  vari¬ 
ables  are  p.nw,  the  number  of  times  that  a  process  p  transits  from  not- waiting 
to  waiting  to  enter  critical  section,  and  p.ne,  the  number  of  times  that  pro¬ 
cess  p  enters  its  critical  section.  We  can  specify  the  progress  property  in 
terms  of  progress  variables: 

{p.nw  >  k)  «— ►  {p.ne  >  k ) 

because  “p  has  entered  its  critical  section  at  least  k  times”  is  a  stable  property 
for  any  k. 

Many  problems,  including  those  in  [1]  can  be  specified  using  ►  rather 
than  -v*.  What,  then,  are  the  disadvantages  of  <— >? 

The  primary  disadvantage  appears  to  be  that  the  use  of  often  re¬ 
quires  the  introduction  of  progress  variables,  and  the  introduction  of  auxil¬ 
iary  variables  can  lead  to  over-specification,  because  auxiliary  variables  can 
be  defined  in  terms  of  an  implementation.  The  introduction  of  p.nw  and 
p.ne  (and  similar  progress  variables  for  other  problems)  does  not,  however, 
appear  to  result  in  over-specification. 

6.2  Compositional  Triples 

Safety  properties  are  compositional,  equation(7).  Progress  properties  are 
not,  in  general,  compositional: 

{U  ^  V  in  P)  A  {U  ^  V  in  Q)  ft  {U  <-+ V  m  P\\Q) 

Compositional  triples  provide  a  way  for  proving  specifications  of  parallel 
compositions  of  programs  from  specifications,  but  not  the  program  texts,  of 
components.  Usually,  in  a  compositional  triple,  the  right  side  is  a  progress 
property,  and  the  left  side  is  a  safety  property  or  a  conjunction  of  safety  and 
progress  properties. 

We  could  have  defined  compositional  triples  in  the  following  way:  if  the 
environment  Q  of  P  has  a  property  U,  then  P\\Q  has  property  V.  This 
definition  was  rejected  because  it  does  not  yield  the  theorem  on  inheritance 
of  compositional  triples,  a  central  theorem  in  our  approach  to  the  design  of 
concurrent  programs.  Also,  this  definition  does  not  yield  transitivity. 
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6.3  Future  Work 


Weakest  Environments  An  intriguing  Line  of  research  is  to  explore  weak¬ 
est  environment,  an  analog  to  weakest  precondition  [2]  for  compositional 
triples.  For  a  given  program  P  and  property  V  can  we  compute  a  weakest 
environment  -  a  weakest  property  U  such  that  [U]P[V]  holds?  If  it  can  be 
computed,  how  can  it  be  used  in  program  derivation? 

For  example,  consider  a  program  P  with  a  single  variable  x ,  and  a  single 
event  that  is  always  enabled  and  increments  a:  by  1.  The  program  can  be 
represented  by  the  do  -  od  loop; 

do  true  — »■  x  :=  x  +  1  od 


Let  V  be  the  property: 

(Vj,  k  ::(x>  j)  ^  (x  >  j  +  k)) 

The  weakest  U  that  satisfies  [F]P[F]  is 

nondecre.asing(x) 

Is  it  possible  to  derive  a  calculus  of  concurrent  program  derivation  based 
on  weakest  environments?  Is  there  a  similar  calculus  for  progress  properties 
using  •— *■? 

Mechanical  Proof  Checkers  Since  the  proof  method  proposed  in  this 
paper  is  based  on  Hoare-triple  rules,  mechanical  proof  checkers  for  sequen¬ 
tial  programs  based  on  Hoare  triples  should  be  extensible  to  handle  proofs 
of  concurrent  programs  using  our  proof  method.  How  difficult  is  such  an 
extension? 

Completeness  We  need  to  explore  the  completeness  of  the  rules  for  <— >. 
The  rule  may  be  incomplete  even  with  the  use  of  auxiliary  variables. 

Proper  Concurrent  Composition  To  what  extent  can  proofs  of  concur¬ 
rent  programs  be  simplified  by  restricting  parallel  composition?  For  instance, 
let  us  define  the  parallel  composition  of  programs  P  and  Q  to  be  proper  if 
and  only  if  in  P||Q,  a  variable  can  be  modified  by  at  most  one  program  — 
either  P  or  Q  but  not  both.  In  this  case: 

U  co  V  in  P  =>  U  co  V  in  P\\Q 

if  V  references  only  variables  modified  by  P.  Likewise,  proofs  of  progress 
properties  can  also  be  simplified. 

Many  concurrent  programs,  especially  programs  using  message-passing, 
are  structured  so  that  parallel  composition  is  proper.  A  line  of  research  is 
to  derive  more  powerful  rules  for  proper  parallel  composition. 
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Evaluating  the  Hypothesis  Our  hypothesis  is  that  most  concurrent  pro¬ 
grams  can  be  proved  using  only  the  well-known  simple  rules  for  Hoare  triples; 
more  complex  rules  and  logics  are  not  needed.  This  hypothesis  needs  to  be 
evaluated  by  studying  a  large  class  of  examples. 

6.4  Past  Work 

This  paper  is  based  on  UNITY  [1],  The  earliest  proof  methods  for  concurrent 
programming  used  Hoare  triples,  and  were  proposed  in  Owicki  and  Gries  [8]. 
The  proof  method  proposed  in  this  paper  is  different  from  that  proposed  by 
Owicki  and  Gries  in  that  noninterference  in  this  paper  is  captured  by  com¬ 
positional  triples  which  are  designed  to  help  in  proving  concurrent  programs 
without  using  the  texts  of  components. 

Compositional  triples  are  very  similar  in  spirit  to  the  rely-guarantee  ap¬ 
proach  proposed  by  Cliff  Jones  [5j.  There  are,  however,  differences  in  the 
definitions.  Compositional  triples  deal  with  parallel  composition  of  any  en¬ 
vironment  and  a  program  P,  such  that  the  composed  program  has  property 
U  —  thus  the  rely  property  is  a  property  of  P  and  its  environment. 

This  paper  is  motivated  by  Hoare ’s  work  on  Hoare  triples  [4].  The  proof 
structure  in  this  paper  is  from  Dijkstra  and  Scholten  [3] 
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